1. Field of the Invention
The invention relates generally to the field of secure communication networks.
2. Background Art
Data exchanged through a network may be copied. Hardware manufacturers hence need to protect the exchanged data and to manage permissions or prohibitions to copy the data. Typically, a Public Key Infrastructure (PKI) is provided: a trusted third party, e.g. a certifying authority, generates private/public keys pairs. The private/public keys pairs are involved in data exchanges between network devices of the network.
The trusted third party signs certificates that contain the public key of the private/public keys pair. Typically, each network device of the network is associated to a determined certificate. The determined certificate may for example be stored within a portable security module of the associated network device. The certificates allow to insure that the data is exchanged between network devices of the network only.
FIG. 1 illustrates an example of a certificate from Prior Art. The certificate 100 is generated by a certifying authority. The certificate 100 comprises an information portion 101 and a signature portion 102.
The information portion 101 comprises at least a public key PUB in a public key field 103, and an identifying field 104 of an associated network device, thus allowing to guarantee that the public key PUB is attached to the associated network device. The information portion 101 further comprises a standard field 105 indicating a standard of the certificate 100 and a validity field 106 that comprises a first date and a second date defining a time interval during which the certificate 100 is valid.
The signature portion 102 is generated from the information portion 101. The certifying authority applies to a content of the information portion 101 a hash function that allows to provide a mark of the content. The mark is subsequently encrypted with a certifying authority private key and the encrypted mark is stored within the signature portion 102.
When an authorized device intends to communicate with the network device, the authorized device checks a validity and an integrity of the certificate 100.
The validity of the certificate 100 is checked from the first date and the second date of the validity field 106.
If the certificate 100 is evaluated as valid, the authorized device subsequently applies the hash function to the content of the information portion 101 of the certificate 100 of the network device. The authorized device decrypts the signature portion 102 with a certifying authority public key associated to the certifying authority private key.
If the hashed content and the decrypted signature portion are similar, the public key of the network device is considered as regular.
A hacker may succeed in replacing a regular public key of a network device by a hacker key. In such a case, the certificate associated to the network device allows to identify the hacker key as fake. Any communication with the network device may subsequently be forbidden.
European Patent application EP 1 253 762, to Thomson Licensing SA, published Oct. 30, 2002, describes an example of a secure communication network involving certificates.
FIG. 2 illustrates an example of a secure communication network as described in the European Patent application EP 1 253 762. The illustrated communication network complies with the SmartRight standard.
A content receiver 201 transmits data to at least one terminal device (221a, 221b). If, for a single content receiver 201, a plurality of terminal devices (221a, 221b) is provided, the terminal devices (221a, 221b) form a local network 222.
Each terminal device (221a, 221b) of the local network 222 comprises a public key PUB certified by a trusted third party, e.g. a certifying authority (not represented). The public key PUB is stored in a certificate (202a, 202b) associated to the terminal device (221a, 221b).
The content receiver 201 receives an encrypted content CW(data) from a content provider. The encrypted data CW(data) are subsequently transmitted to the terminal devices (221a, 221b) of the local network 222.
The received content may be a pay television program. The content provider 206 may be a broadcaster, e.g. a satellite broadcaster. Each terminal device (221a, 221b) typically comprises a content presentation device (216a, 216b), e.g. a television set, and a portable security module (220a, 220b), e.g. a smartcard.
The encrypted content CW(data) is broadcast in a data stream F. The data stream F further comprises an Entitlement Control Message (ECM) that contains an encoded Control Word K(CW). The Control Word CW allows to decrypt the encrypted content CW(data). A plurality of keys are involved in a descrambling of the encrypted content CW(data) and the certificates (202a, 202b) are used to obtain some of the keys.
Typically, when a new network device is installed in the local network, the associated certificate allows to access a symmetric network key Kn. The symmetric network key is subsequently used to communicate a newly generated symmetric key Kc and the certificates are involved in the communicating. Furthermore, a validity of the certificate may be checked to allow the associated terminal device to decrypt the encrypted content.
FIG. 3 contains a time chart illustrating a communicating of a symmetric network key between a progenitor terminal device and a new terminal device at an installing of the new terminal device within a local network, according to the European Patent application EP 1 253 762.
A progenitor terminal device 321a possesses a symmetric network key Kn. When a new terminal device 321b is installed in a local network, the progenitor terminal device 321a reads a certificate 302b associated to the new terminal device 321b. A content of an information portion 303b and a content of a signature portion 304b are processed so as to evaluate if a public key PUB is properly associated to the new terminal device 321b. A validity of the certificate is also checked from a validity field 312b of the certificate 302b. 
The new terminal device 321b transmits to the progenitor device 321a the public key PUB stored in the certificate 302b. The progenitor device 321a receives the transmitted public key PUB and encrypts a symmetric network key Kn with the received public key PUB. The encrypted symmetric network key PUB(Kn) is subsequently transmitted to the new terminal device 321b. A private key PRI stored in the new terminal device 321b allows to decrypt the encrypted symmetric network key PUB(Kn).
The symmetric network key Kn is used for exchanging data with the terminal devices (321a, 321b) of the local network.
Referring now to FIG. 2, the content receiver 201 receives the data stream F from the content provider 206. The data stream F comprises the encrypted content CW(data) and an Entitlement Control Message (ECM). The ECM comprises the encoded Control Word K(CW) itself, the Control Word CW being encoded by a key K.
The content receiver 201 comprises a decoder 217 and a receiver portable security module 218, e.g. a smartcard The content receiver 201 allows to decode and to re-encode the received Control Word CW, the Control Word CW being re-encoded with a symmetric key Kc. The encrypted data CW(data) and the re-encoded Control Word Kc(CW) are transmitted to at least one terminal device (221a, 221b).
The symmetric key Kc is preferably periodically renewed, for example on initiating each data transmission.
FIG. 4 schematically illustrates an example of a scrambled symmetric key Kn(Kc) acquisition from Prior Art A content receiver 401 checks to see if a certificate 402 guaranties that a public key PUB associated to a terminal device 421 is regular. A validity of the certificate 402 is also checked from a validity field 405 of the certificate 402.
The content receiver 401 subsequently transmits a new symmetric key Kc to the terminal device 421, the transmitted symmetric key Kc being scrambled with the public key PUB. The terminal device 421 descrambles the scrambled symmetric key Kc with an associated private key PRI stored in the terminal device 421. The terminal device 421 subsequently re-scrambles the symmetric key Kc with a symmetric network key Kn. The content receiver 401 receives from the terminal device 421 the re-scrambled symmetric key Kn(Kc). The symmetric key Kc is stored within the content receiver 401 in its scrambled form Kn(Kc).
Referring now to FIG. 2, the content receiver 201 possesses the symmetric key Kc in its scrambled form Kn(Kc) following the acquisition.
The content receiver 201 transmits to the terminal devices (221a, 221b) the scrambled symmetric key Kn(Kc) and the processed data stream, i.e. the encrypted content CW(data) and the re-encoded Control Word Kc(CW).
Each terminal device (221a, 221b) may subsequently descramble the symmetric key Kn(Kc) with the symmetric network key Kn. The symmetric key Kc allows to decode the re-encoded Control Word Kc(CW), and hence to decrypt the encrypted content CW(data). A validity of each certificate (202a, 202b) is checked before allowing any decrypting of the received content.
However, a hacker could perhaps succeed in obtaining the public key and insert unauthorized terminal devices into the local network.
In order to improve security in prior art systems, the public key may be replaced by a key having a bigger size so as to reinforce an encryption: for example, a 1024 bits RSA algorithm may be replaced by a 2048 bits RSA algorithm. An encryption algorithm or a standard of the certificate may also be updated, e.g. the RSA algorithm is replaced by a more secure cryptography algorithm. The certificates are hence periodically updated, e.g. once a year.
The validity of a determined certificate may be checked several times, e.g. at an installing of a new terminal device into the secure communication network, or when a new symmetric key Kc is generated and transmitted to the terminal device, as illustrated in FIG. 4. A continuous checking of the validity may be also performed, so as to insure that an owner of the terminal device is allowed to access the received content.
FIG. 5 illustrates an example of a system for checking a validity of a certificate from prior art. The certificate 500 may comply with the X509 standard and comprise a validity field 506 that stipulates from which starting date to which end date the certificate 500 may be considered as valid. Accordingly, the validity field 506 contains a first date 508 and a second date 509 that form a time interval during which the certificate 500 may be considered as valid.
Processing means 510 of an associated terminal device 521 allow to compare the first date 508 and the second date 509 of the certificate 500 to a current date furnished by a clock 507 so as to evaluate a validity of the certificate 500.
If the current date belongs to the time interval defined by the first date and the second date, the certificate 500 is considered as valid: the public key PUB of the certificate 202 may be accessed, thus indirectly allowing to decrypt a received encrypted content 511.
If the current date is outside the time interval, it is considered that the certificate 500 has expired, or that the certificate 500 is not valid yet.
In a case of a pay television system, the certificate 500 may be periodically updated or replaced. If a subscriber stops paying a rental, the certificate 500 is not replaced and the content terminal 521 is no longer able to decrypt the received encrypted content 511.
The validity of a given certificate may also be evaluated via a Certificate revocation List (CRL) that comprises revoked certificates or identifiers of the revoked certificates. A certificate of a terminal device is considered as valid as long as it is not mentioned within the CRL. If a hacker succeeds in obtaining a determined certificate, a trusted third party append the determined certificate to the latest CRL.
Typically, the validity of a certificate is evaluated following a two-steps procedure: both a validity field of the certificate and a CRL are involved in the evaluating. The validity field comprises a first date and a second date forming a time interval during which the certificate is expected to be valid. However, if a hacker succeeds in accessing a protected content, the certificate may be disabled sooner than expected: a new CRL is generated, the new CRL comprising an identifier of the disabled certificate. The disabled certificate is hence evaluated as valid at a first step of the evaluating, the first step involving only the validity field; at a second step of the evaluating, an identifier of the disabled certificate is found among the revoked certificate identifiers of the CRL and the disabled certificate is definitely evaluated as invalid.